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[57] ABSTRACT 

/C file~a^catiorPand m anagement system for a multi-user 
network environment is~b^sclosedrATleast one server and 
two or more clients are dis posed alon g the network in 
communicating~via' a request/response transfer protocol. 
Files directed for shared usag e among the clients along th e 
netw^rk_a^stored^at_the_seryer. Ea ch client is adap ted to 
c qmmun icate _with the server throu gh a, pluralit y_of ident ifier 
sockets, wherei n a first ide atifier_s ocket is confi g ured fo r 
hiiduectionalxommunicatOT 

is configured for unidirectional commufHGations-initiated by 
the server. Files normally sto red at the server, under ap pro- 
priate circumstancesjjiay be .te mporarily stored in an inte r- 
n al cache or other memorY^t.each^lig^lo^jion, wh en the 
file isia.use' 
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SYSTEM AND METHOD FOR PROVIDING read-write access and makes certain modifications to the file, 

OPPORTUNISTIC FILE ACCESS IN A but retains the file in its local cache for further use. At some 

NETWORK ENVIRONMENT time later, client B retrieves the file for read-only access. It 

should be appreciated that the file, as retrieved by client B, 

This is a continuation of application Ser. No. 08/478,454, 5 is in its original state, since the modifications made by client 

filed on Jun. 7, 1995, now U.S. Pat. No. 5,628,005. A have not yet been written back to the server. The earlier 

modifications made by client A to the file are not apparent to 

BACKGROUND OF THE INVENTION client B and may have potentially disastrous effects, depend- 
ing of course, upon the particular application running at 

1. Field of the Art 1Q client B . 

The present invention relates generally to shared resource A simikr problem a[iscs $ client A retrieves a file for 

allocation in a multi-user networking environment, and rea d- 0 nly access. At some later time client B retrieves the 

more particularly, to a system providing opportunistic file file with rcad _ write acccss and makes modifications to the 

access control over shared resources in a multi-user net- file modifications we transparent to client A, which 

working environment. is ^ st iu operating with the original file contents in its cache. 

2. Discussion of the Related Art It can ^ apprec i at ed from the foregoing description that 
A typical computer networking system consists of a some type of file or resource management system must be 

number of individual nodes, including at least one server implemented at the server to maintain the integrity of the 

node and two or more client nodes, interconnected through fii cs centrally stored at the server location. Indeed, some 

a network link. Broadly, the server manages resources 20 systems have solved this problem by providing an absolute 

directed for shared usage among a number of clients on the ] oc k a t the file server, permitting only one client (having 

network. More specifically, a file server manages a disk or read- write authorization) access to a file at any given time, 

other device for storing files to be shared by various clients That one client must, therefore, write the file back to the 

throughout the network. server before another client is allowed to access the file. The 

As is known by persons of ordinary skill in the art, a 25 problem, however, created in this type of system is that a 

bottleneck in networking environments is the network link second client requesting access to a locked file has no 

that interconnects the nodes. The primary reason for this indication of when the file will be released by the client 

bottleneck is the bandwidth of the physical medium com- having present access to the file. Accordingly, it is further 

prising the network link — whether it is twisted-pair, coax, or desired to provide a system having a way of forcing a client 

fiber-optic cabling — as the bandwidth determines the maxi- 30 to release control of a file that it has retrieved into its local 

mum rate that data can be communicated across the link. cache. 

Reducing the number and amount of data transfers across This problem is broadly addressed by U.S. Pat. No. 

the network link will correspondingly lessen the deleterious ' 4,887,204 ('204 patent) to Johnson et al., and assigned to 

effects of the bottleneck and, accordingly, enhance overall ^ International Business Machines Corporation (IBM®). The 

network system performance. '204 patent solves this problem by providing a plurality of 

One known way to reduce the number of network trans- "synchronization modes". Specifically, three synchroniza- 

fers is to temporarily store files retrieved from a file server tion modes are provided. The system of the '204 patent 

in the retrieving client's local memory space, usually a cache operates in a first synchronization mode (A_synch mode) 

memory. When a client requests multiple or repeated access ^ when a file is being accessed by a single client with 

to a file stored on a file server, that file is written into the read-write authorization. The system operates in a second 

requesting client's local cache until that client is finished synchronization mode (Read_only mode) when one or more 

with the file, at which time the file is written back to the clients have accessed a file, each with read-only authoriza- 

server (if changed). In this manner, overall system perfor- tion. Finally, the system operates in a third synchronization 

mance is improved by eliminating unnecessary intermediate 45 mode (Full_synch mode) when multiple clients have access 

file transfers over the network. In the context of the present to a common file, and at least one client has retrieved the file 

invention, and as used herein, the term "file" refers to any with read-write authorization. 

collection of information or data regardless of size or i n either the A_synch or Read_only modes mentioned 
whether the information or data is merely a portion or subset above, the file is transmitted from the server into the local 
of a larger collection of information or data, e.g. sectors, 5Q cache of each client having access to that file. In the 
blocks, records or the like. Full_synch mode, however, the shared file is maintained at 
Problems arise, however, when two or more clients need the server, so that any read or write operation must take 
access to the same file stored at the server, and one or more place through transfers over the network. Although opera- 
clients need read-write access to that file. To provide a tions in this mode necessarily degrade the network 
simple illustration of this problem, suppose client A and 55 performance, the mode nevertheless provides an effective 
client B both retrieve the same file from a server for way of maintaining file integrity while allowing multiple 
read-write access, whereby the same file is simultaneously client file access. 

residing in the local caches of both client A and client B. jh c >204 patent further describes the dynamics of the 

Assume further that both clients make modifications to the synchronization modes as multiple clients request and 

file. If client A writes the file back to the server first, when 60 release access to various files in the network environment, 

client B writes the file back to the server, the changes made p 0 r example, if client A is the first client to access a file from 

by client A will be destroyed. Moreover, client A will be the server and requests read-write access to that file, then 

unaware that its changes were overwritten. that file is transferred to client A's local cache in the 

The same problem, although not as obvious, can arise A^_synch mode. If at some later time client B requests the 

where multiple clients have retrieved a file into their local 65 same file for read-only access, then the server requests client 

cache, but just one client has requested read -write access. A to change to the full-synchronization mode (See col. 21 

For example, suppose that client A retrieves a file for lines 19-22). Client A responds by flushing that file from its 
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local cache and writing back to the server any portions of the examination of the following or may be learned with the 

file that were changed by client A. At this point, both client practice of the invention. The objects and advantages of the 

A and client B must access the file, which will be maintained invention may be realized and obtained by means of the 

at the server, over the network link. If at some later time instrumentalities and combinations particularly pointed out 

client A has completed operations on the file, it instructs the 5 in the appended claims. 

server that it is finished. The file's synchronization mode is jo achieve the foregoing and other objects, a preferred 

then changed to Read_only, and the file is transferred from embodiment of the present invention is generally directed to 

the server to client B's local cache. Subsequent reads from a file allocation and management system for a multi-user 

client B then can be accommodated locally, without requir- network environment of the type having at least one server 

ing transfers over the network link. 10 an j two or more clients that communicate in a request/ 

The above solution, while workable, has certain draw- response transfer protocol. Files directed for time-multiplex 

backs and deficiencies. More specifically, the '204 patent shared usage are stored at the server. Each client is adapted 

addresses the shared resource management problem in the to communicate with the server through a plurality of 

broad sense by assuming, for purposes of that invention, free identifier sockets, wherein a first identifier socket is config- 

two-way communication between the server/ and clients. 15 ured for bi-directional communication between the client 

Indeed, columns 20-22 discuss changing from A__synch to and server, and a second identifier socket is configured for 

Full_synch and from Read_only to Full_synch synchro- uni -directional communications initiated by the server. The 

nization modes. In each of these instances, it is assumed that bi-directional communications through the first identifier 

the server has direct command control over each client (See socket are initiated by a client request, consistent with the 

col. 21, lines 19-21 and col. 22 lines 12-15), whereby the 20 request/response transfer protocol. Each client further 

server may direct a client to release a file residing in its local includes an internal cache memory for temporarily storing 

cache. The file management as taught by the '204 patent, files that have been transmitted to the client across the 

wherein a file lock at a client may be broken, is often network, 
referred to as an opportunistic lock. 

However, present systems are known that empby a "ping » BRIEF DESCRIPTION OF THE DRAWINGS 

pong," or request/response, transfer protocol of information The accompanying drawings incorporated in and forming 

exchange between client and server. In such systems, com- a part of the specification, illustrate several aspects of the 

mand sequences are initiated by the client, whereby a client present invention, and together with the description serve to 

submits a command or request to the server and then awaits explain the principals of the invention. In the drawings: 

the server's response. If a client has not initiated a request 30 F]G ± ^ a schematic representation of a typical network- 

of the server, it has no reason to monitor the network link mg erjv ironment used by the preferred embodiment of the 

and may therefore ignore commands initiated by the server. prese nt invention depicting the Open Systems Interconnec- 

Accordingly, the server generally cannot unilaterally com- ^ 0J]S ( 0SI ) network layers; 

mand a client to release its control of a particular file. ^ mQ 2 fa ^ Ipx@ packet used tQ 
To more particularly illustrate this problem, suppose communicate over the network, and further shows the nest- 
client A is the first client to request access from a file stored mg of this packet ^tween the medium access protocol 
at the server, and requests to have such access with read- envelope and me request/response packet; 

write authorization. Since no other client has contempora- C1 ™ a* a 1ri , „ A «.»™*™ u^u , 

4 tL . C1 e j ■ 4„r_J» a»- FIGS, 3A and 3B show the record structure tor both a 

neous access to this file, the file is transferred into client A s tn . . tU MPD 

, , . r . 1 \ t> * *~*u~ fiu 40 request and response packet using the NCP protocol; 

local cache. Later, client B requests access to the same file v . 

from the server. The server must then signal client A to ™ 4 is a schematic diagram illustrating the primary 

release its exclusive access over the file and flush its local elements of the network of FIG. 1; 

cache. However, in a system having a typical request/ FIG. 5 is a top-level flowchart depicting the top level 

response transfer protocol, client A will not be listening to ^ operation of the file management system of the present 

the network link and, thus, will not know of client B *s desire invention; 

to access the file. As a result, the operation at client B will FIGS. 6A and 6B collectively are a flowchart more 

either be suspended, or at least unduly slowed while client particularly depicting the operation of the file management 

B awaits to receive the file from the server. system of the present invention upon receiving a request by 

It can be appreciated from the foregoing discussion, that 5Q a remote client, for access to a file stored at the server; and 

a need exists for a system to provide opportunistic access to FIGS. 7A-7B collectively are flowcharts depicting the 

a file in a system of the type having a request/response operation of the file management system of the present 

transfer protocol, whereby informational exchanges may be invention upon receiving notification from a remote client 

instituted upon a client's request, even if another client is that the client is relinquishing access to a file, 

presently accessing the same file. 55 Reference will now be made in detail to the preferred 

SUMMARY OF THE INVENTION embodiment of the present invention, which is illustrated in 

the accompanying drawings. 

Accordingly, it is a primary object of the present invention 

to proyja^_aalii^pcayed file management sy^em_having DETAILED DESCRIPTION OF THE 

g ^rtu^sticfileloc^ inTn^r^rk^iTo^ment havin g a 60 PREFERRED EMBODIMENTS 

reS^^rSponsci ransfer protoc ol a typical networking system comprises at least one server 

Another object of the present invention is to provid e a file and two or more clients interconnected through a network 

nanagement svstern_tbat minimizes the number, o f file link. For purposes of the present invention, the particular 

transfers across the netwo rk. type of network link or style of network topology is irrel- 
Additional objects, advantages and other novel feature s of 65 evant. Indeed, the International Standards Organization 

th e invention will be set forth in the description that fo llows (ISO) has published specifications for their OSI reference 

and will become apparent to those skilled in the art upon model for layered data communications, which has become 
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a standard framework for describing network communica- referred to as connectionless because no physical routing 

lions systems. The ISO reference model is divided into channel is established before transmitting the message, 

seven layers, each defining a set of services and related Instead, the message packet is formed and placed on the 

protocols for handling messages at that layer. network link without ensuring whether it was ever received 

Specifically, and as understood by persons of ordinary 5 by the destination node. Any such guarantees for proper 

skill in the art, ISO's reference model defines the following packet transmission must be provided by a higher level 

seven layers: (1) physical; (2) data link; (3) network; (4) transport protocol. For more information on the IPX® 

transport; (5) session; (6) presentation; and (7) application. protocol, reference is made to NetWare The Professional 

This layering of functions and protocols provides the basis Reference, by Karanjit Siyan, 2nd ed. (Copyright 1993 by 

for communication between dissimilar types of network 10 New Riders Publishing), which is hereby incorporated by 

hardware and software, although not all networks are reference. 

designed to fit neatly within this rigid structure. Since the One such higher level protocol is Netware Core Protocol 

concepts and teachings of the present invention generally (NCP), which was designed to run in conjunction with 

fall within the transport through application layers, discus- IPX®. Additional information regarding the NCP protocol 

sions of the operations taking place at the lowermost (e.g., 15 can be found in an article by Pawel Szczerbina entitled 

physical, data link, and network) layers are not necessary for "Novell's NetWare® Core Protocol," Dr. Dobb's Journal, 

purposes of describing the present invention, as the opera- November, 1993, pp. 123-132, which is herein incorporated 

tions at these levels are known to those skilled in the art and by reference. 

are transparent to the operations of the present invention. Th e preferred embodiment of the present invention uses 

Referring now to the figures, FIG. 1 shows a diagram- 20 the request/response transfer protocol of NCP. In this way, 

matic representation of a typical networking environment the present invention can be used in conjunction with higher 

used by the present invention, and is generally designated as level programmed applications, that are directed to the NCP 

reference numeral 100. The physical hardware components environment. 

reside at the lowermost OSI layer, or physical layer, and More specific reference is now made to FIG. 2, which 
include the various nodes distributed along the network link 25 displays the IPX® packet structure and the nesting of 
or cabling. Although the term 'node' broadly refers to all information packets through progressive OSI layers. An 
types of physical devices attached to the network link, only NCT request/response 116 command packet, which will be 
client and server nodes are depicted in FIG. 1. discussed in greater detail in connection with FIGS. 3A and 
More specifically, FIG. 1 illustrates two clients 102, 104 3Q 3B, is nested within the IPX® packet 114, which is nested 
and a single server 106, interconnected through a network within the medium access protocol envelope 118. As 
link 108, although additional clients and servers, as well as illustrated, the IPX® packet format is primarily concerned 
other types of nodes, may be distributed along the network with routing information, such as the packet source and 
link as well. As used in this specification, the term 'client' destination. The specific identifiers are network, node, and 
will generally denote a user workstation of some type. The 35 socket number. The network number identifier enables corn- 
term 'server' can include any device directed for controlling munication among multiple networks. The node number, 
and coordinating shared usage of a network resource, such identifies the particular node address on the network, and the 
as a storage disk or printer, but as used in this specification socket number identifies the particular process within that 
for describing the concepts and teachings of the present node. 

invention, unless otherwise indicated, it will refer to a file ^ To more particularly describe the significance of the 

server. socket number, multiple processes may be running under a 

The next OSI layer, the data link layer, is directed to the single node at any given time. For example, the popular 

transmission of data streams that enable communication Microsoft Windows® multi-tasking operating system can 

among the nodes at the physical layer, and is commonly accommodate several tasks or processes at any given time, 

referred to as medium access 109. Bits of information are 45 on the same physical node. To uniquely associate commu- 

typically arranged in logical units known as frames or nication packets with each of these processes, a unique 

envelopes 118 (See FIG. 2). These envelopes define the socket number is used. For illustrative purposes, in a pre- 

protocol which the physical nodes use to intercommunicate. ferred embodiment of the present invention, three sequen- 

Ethemet and Token Ring are examples of popular frame/ tially addressed sockets are shown associated with each 

physical protocols used in networking systems. Typically, 50 process, and will be described in more detail below, 

the envelopes 118 are divided into segments including a Referring now to FJGS. 3 A and 3B, the packet structure 

header 110, a trailer 112, and a data segment. The header 110 for a request (FIG. 3A) and response (FIG. 3B) packet for 

includes information such as the physical address of the the NCP protocol are shown. In connection with FIGS. 3 A 

destination node, which enables any given node to direct a and 3B, reference is once again made to the cited pages of 

communication to another specified node number. The 55 the November, 1993 issue of Dr. Dobb 's journal wherein a 

trailer 112 usually provides some type of parity or other data description of the packet structures for the NCP protocol are 

integrity check, to ensure proper data transmission. Finally, set forth in sufficient detail to enable one of ordinary skill in 

the data segment includes the information embedded and the art to effectuate the concepts and teachings of the present 

passed down from the higher OSI layers. (FIG. 2 depicts this invention as described herein. Brieflv. however, the reque st 

successive data embedding) go packet d epicts the inf o rmation contained in the commu ni- 

The network layer builds on the data link layer and is ca ri6^da tagrar£ jransmitted from a client to th e server, 
directed to the routing of information packets among the whereas the response packet depicts the information con- 
physical nodes. In the preferred embodiment of the present tained in a communications datagram transmitted from the 
invention, the Internetwork Packet Exchange (IPX®) 114, a server to the requesting client. 

Novell® protocol, is used to provide the network layer 65 Having now described the environment in which the 

protocol. IPX® is a connectionless datagram protocol that present invention operates, the discussion will now be 
provides services above the medium access layer. It is directed to the detailed operation of the present invention. 
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FIG. 4 schematically represents the primary network archi- 
tecture supporting the operation of the present invention. A 
network link 200 provides the medium for communication 
among a plurality (2 to n) of clients 202 and 204 and a file 
server 206. In the preferred embodiment, the clients 202 and 
204 are personal computer workstations operating in a 
Microsoft windowing environment and contain cache 
memories 210 and 211 and cache controllers 212 and 213, 
respectively. It should be appreciated that the network link 
is not limited to any tangible medium but, indeed, could 
comprise twisted pair, co-axial, or fiber-optic cabling, as 
well as satellite communication. A resource 208, such as a 
disk drive, is located at the server 206 and provides perma- 
nent storage of files for shared usage among the clients 
throughout the network. 

According to the standard NCP protoco l, three sockets are 
sej_u pj>y software ea ch time_aj^twor^ process irinj tiated*. 
Asshown in the hiu7~4; sockets I 147215 and 218 serve- as 
ports through which communication packets aretransferred 
between the process running on the client 202 and server 
206. More particularly, socket 214 and 218 are ports pro- 
viding bi-directional communication between the client 202 
and server 206, whereas socket 216 is a port that supports 
only uni-directional transfers of communication packets 
from the server 206 to the client 202. Although both sockets 
t - 214 and 218 support bi-directional communication, socket 2 5 
W21j$(the main socket) provides general bi-directional 
communication, while socket 218 supports tonly a specific 
type of communication, as will be described below. 
The second socket 216, called the message socket, is 
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Generally, the file management system of the present 
invention operates in the following manner. A process 
requests files by submitting a request to the server 206 
through its first socket. The server 206 maintains a file table 
220, which is stored in the internal memory 205 of the server 
206 and contains a current list of open files to which clients 
have access and information on how the files are being 
accessed. When the server 206 receives a request for access 
to a file from a process, the server 206 examines its file table 
220 to determine whether access to the requested file should 
be granted. 

By way of example, the file table 220 of FIG. 4 shows that 
"Namel" is presently being accessed with read-writeauthor- 
ity'fiyl proce ss #2; file "Name2" is presently being accessed 
with_read-only authorization by process. #1: file "Name3 w is 
presently being accessed by processes #1. #3 and #4; and file 
"NameX" is being accessed by process #Y withjead-only 
authorization. File table 220 also im piicitlvJde ntifies whic h 
files are opportunistically locked by the processes and whi ch 
fi les are being maintained by the server . For example, since 
file "Name I" is being accessed by only one process (process 
#2), it is being maintained in the local cache memory of the 
client ru n ning (process'#2r; Similar] y, o nl y process , #1. has 
access to file "Name2." Accordingly, process #1 is giyen^an 
opport^isTicTock on fileJ^Name2" and maintains the file in 
the local cache memory of its client Asfor fi le "Name3." it 
Ls_being accessed by multiple^ prn^ss^^ l ^and-therefore T if is 
maintainejOndIlocate_d-at the^seryer_206. Although not 
reqiure cMhe Jp_^ u Name3" is stored in.th e Int ernal me mory 



generally used by the server to notify the client if it has a 30 space 205ToTthe server 206^ It should be appreaatecTtEat 

storing file "Name3" in the internal memory to, server 206, 
r ather than the. resQurce-208. saves'file~transi'ers3ionfi t he 
link connectihg_the.server-206 to its.resourc&J&jL 

Alternatively, the file table 220 may explicitly maintain 
35 information regarding the opportunistic locked status of a 
file. For example, an oplock flag or a field in the file table 
220 may be set or maintained to indicate whether a file is 
opportunistically locked or maintained at the server or 
whether a particular process had or desi red an oppo rtunistic 
40 l ock on a fil e. The maintenance of such flags or fields 
re present a trade-off between the memor y a nd, overh e ad 
requirements to store_a nd.maint ain_the file table 220 and the 
spee d at_whi ch th e determinat ion^oLoplock slatus.oLaJ51e is 
obtainable. 

45 With the file table 220 in the state described above, if 
process #1 is running o n cl ieat-A-anxLan other pr ocess 
running . on a different client requested thejile "Name2" for 
r ead- write jicces s, the server 206 would recognize fro ra, the 
fi lejable 220 that file "Name2" was presently inlMJocal 



message (for example, from another client on the network) 
for Ahe^ client.J f the client desires the contents of the 
message, the client makes such a request to the server via the 
main socket _214. As described in more detail below, this 
second socket 216 has been adapted for use by the server 
206 in connection with the present invention to submit 
requests to the client 202, namely tnrelease its opp ortunis tic 
l ock on files that are^maintained-in 4 hR-C;lipnt~cac^e-njemory 
210. 

A third socket 218, called a watchdog socket, is adapted 
to receive inquiries from the server as to. the status of a 
process or client connection. Specifically, in situations 
where a process, although presently active, has not commu- 
nicated with the server for long period of time, the server 
206 will submit a request to the third socket 218 inquiring 
whether the client wishes to terminate the process. If the 
client 202 wishes to maintain the process, it informs the 
server by responding through the same socket 218. 
Otherwise, the server 206 terminates the connection with 
that process. 



As previously described, the identifier sockets are set up 50 memory space of process #1. The server 206 would then 

by software and serve as communication ports through transmiLa-reouest to the second socket 216 of procesjjl to 

which network transfer packets are exchanged between r elinquish cop|r olof file "Name2". Process #k»EP n receiv- 

client and server. As should be appreciated by one of inftjthe requesTthrough the second socket 216, -would .then 

ordinary skilled in the art, a hardware interface 217 and 219 flush file "r^ame2" from it s cache memo ry 210 and instruct 

at each client is provided to buffer the information or data 55 the server 206 ^thiQugh_ its first socket 214 that it had 

exchange between the client and server. Broadl y, the inte r- relinojiishe d - thf . file It is im portant to note that the file n eed 

face 217joperates to receiye.data transmitte£^heseryer by not_be _transmitted over the network to the server 206 since 

monitoring the data being transmitted .aCTOSSjhe.. network process #1 had readonly access to the file and no cha nges 

link 200rUponTdentify1ng an IPX data packet in which the would have been made to the file. In contrast, if the process 

network, node, and socket identifiers (as shown in FIG. 2) 60 h ad requested access to file "Namel". then process #2 would 

correspond to a socket under a process running at client A, need to transm it any of the modified^rtions of the file from 

then the interface 217 will capture this data packet from the its cache 210 to the server ZU ft. ~>^_. 

network link 200 and transmit it to the appropriate socket. If a process requests access to a file which is not in the file 

Similarly, the interface 217 will take a transmission from table 220, the server 206 recognizes that the file is not 

socket #1, format it for transmission over the network link 65 presentlv_beina accessed by an y other _processes. 

200, and place it on the network for transmission to another Accordingly, the processjs_given an opportun istic loc k on 

node. th e file an d the file table 220 is updated accordingly. 



AM* fS 
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The foregoing examples generally illustrate the manner in 
which file maintenance is maintained in a system of the 
present invention. Reference will now be made to the more 
specific operation illustrating the file control features of the 
present invention. 

FIG. 5 shows a top level flowchart of the server routine for 
the present invention. The routine operates in such a manner 
that the server waits for a remote process to either reques t or 
relin quish access to affile stored at the server resou rce z08 
(step 230). Upon receiving an appropriate signal, the server 
206 then determines, at step 232, whether the remote^process 
is requesting or jelinquishing-accessjo. a file. If the process 
has requested access to a file, the server 206 checks its file 
table 220^ to determine whether the requesting process may 
be given an opportunistic lock on the requested file (step 
234). An opportunistic lock is granted if 1) the requesting 
process is the^ only process requesting access to the file, or 
2) the requesting process is seeking read-only access to the 
file and no other processes have read-write access to the file. 
If the opportunistic lock is granted, then the server 206 
transmits the file to the process using the first socket of the 
requesting process, updates its file table 220 to indicate the 
requesting process has access to the file and the . type of 
access (e.g., read-only or read-write); and notifies the 
requesting process that it may maintain the file locally, in its 
local cache or other storage resource available to it (step 
238). If an_opportunistic lock is not granted, jhejHheseryer 
206 n otifies jhe re mpte_pjo^essjhat Jhejfile^must^ejnain- 
tained^t_the_sei^e^ft6 (step 240). >TBe server 206, 
nevertheless, updates its file table 220 to indicate that the 
process has access to the file and the type of file access, and 
transmits the file to the first socket of the requesting process. 

If, at step 232, the server 206 determines that the remote 
process is relinquishing access to a file, then the server 
examines its file table 220 to determine whether the relin- 
quishing, prpcess.hasjoppojrtunistic access to the file, i.e. 
whether,the_file is presentl y mai ntained in t he cac faeojF the 
relinquishing ^process (step 242). If so, the server. 206 
retrieves any modified portion of the hie through me fi rst 
sock et of the remote process, and updateTits~file "table 2 20 
accordinj>Iy_( step 244). 

Whether the relinquishing process had opportunistic 
access to the file or not, the act of relinquishing a file by one 
process may effect how other processes mayjiow access the 
file. Accordingly, the server 206 updates and examines its 
file table 220 to determine if any other processes which are 
currently accessing Jhe_ file may be granted opportu nistic 
a ccess to the file, i.e. wbetherjhe file^h]5ukf be transmitted 
out to_ the local cache of one or more ot her clients (s tep 246). 

FIG. 6 shows a detailed software.flowchart setting forth 
the .routine of the ser ver 2 06 for allocating files when_[t 
recdves_a^ request. Upon receiving aj-eguest forajile (step 
250), the server 206 examines its file table 220to determine 
whether the file is in use (step 251). If the file is not in the 
file table 22P, it is not presently being.acce ssed by^an y other 
process, and accordingly, the server 206 transmits the file to 
the first socket of the requesting process and notifies the 
requesting process that it has been granted, an opportunistic 
lock on the file (step 252). The server 206 will then update 
its file table indicating that the remote process has access to 
the file and indicating the manner in which the process has 
access, i.e. read-only or read- write authorization. 

If the server 206 determines at step 251 from examining 
its file table 220 that the file is presently being accessed by 
other remote processes, it must then ascertain whether the 
requesting process has requested read-writs nr read-only 



10 



30 



35 



40 



45 



50 



55 



60 



a uthorization (step 254). If the requesting pro ces s ha s 
r equested the hie for react-only authonzation'theirthe^ erver 
206 detennines from the file table whether any" o ther process 
presently has read-write authorization tor the~Ifle~(step 256). 
If not, the server 206 recognizes that the other processes 
have read-only opportunistic locks on the requested file, and 
accordingly, transmits the file to the first socket of the 
requesting process; notifies the requesting process that it has 
been granted an opportunistic lock on the file; and updates 
its file table as described in connection with step 252. 

If the server 206 determines at step 256 that another 
process presently has read^wri|.e^acce ss to the file, its actions 
will depend upon whether mor^tnan one process presendy 
h as access to the fil e. If t he file server 206 determines at_s tep 
257 that only a sin gle remotej jr ocess has access to a file wit h 
rea^-wT^aumorizationJ^ 

tf^loc aj_memo ry_of jhe single remote process b y wayj)f an 
op portunistic lock - In such a case, the server 206 transmits 
a message to the second socket of the single remote process 
indicating that another process wants access to the file and 
requesting that process to transmit the file back t o the se rver 
206 (step 258). The server 206 then waits for the si ngle 
remote processloj ran^irtD^flle ^b ack to the server 206 
(step"2^0). Inthe preferred embodi ment, the remote proc ess 
wfll tran^mif^ 

modified since retrieving the file from the serveL ~2Q6, 
thereby minimizing traffic over the netw ork link.: If the 
server 206 has waite d so me predetermined period of ti me 
(e~.g. 50 mifiiseconoiy" wu r hout receivin g the file it wi ll 
t imeout at step 262. assume that a messag ej iacket was lost, 
a nd retrapsm it.the.request.to. the remote proce ss (step 264). 

When the requested file is transmitted back toj jie server 
206 through the first socket of the sind e reniQte-PEOcess, the 
serv er 206 transmits a message to the first socket of the 
req uesting process tha tthsJil e isavailable at the "serve r 206 
flndjhat the requesting -process isgrant ed remote accessJo 
th^fiieTstep 266Uhe_serve r 206 also update its file tab le \ 
220 accordingly . * 

If the file server 206 at ste p 254 deter mines that th e 
remote_process req uests read-write authorization for th e file, 
then it checks.its Jfejable^20jo_see if any .ot her process 
presently has read- write.access-to-the.file,(sle p_ 270)71 f not, 
then the file"isf3eing maintained in the local memories of the 
other remote processes by way of an opportunistic lock. 
Accordingly, .the server 206 transm its a messa ge_to_the 
second s ocket of eacb _ ofjhese processes, req uesting each 
process to relinquish opportunistic acce^^dcontrol of the 
requested file (step 272). The server 206 then waits for each 
process so requested to transmit an acknowledgement 
through its first socket that it has relinquished opportunistic 
access and control of the file (step 274). It should be 
appreciated, that since these processes have read-only autho- 
rization to the file, that the file may simply be flushed from 
their cache memories, and does not need to be transmitted 
over the network link. If all such requested processes have 
not responded to the server 206 within a pre-determined 
period of time (e.g. 50 milliseconds), the server 206 will 
timeout and assume that a message packet was lost in 
communicating with any such non-responding processes 
(step 276). For these processes, the server 206 will retrans- 
mit the message packet to socket #2 (step 278). Once all 
requested process have notified the server 206 that they have 
relinquish opportunistic access and control of the file, the 
server 206 transmits a message to the first socket of the 
requesting process that the file is available at the server 206 
and that the requesting process is granted remote access to 
the file (step 266). The server 206 also update its file table 
220 accordingly. 



> server ftKcAS" 
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If, however, another process does have read-write autho- 
rization (step 270), then the server determines whether more 
than one process has present access to the file (step 257). 
From this point, operation of the invention will proceed as 
previously described. 

Reference is now made to FIGS. 7A and 7B, which 
together show the software flowchart for the routine of the 
server 206 when a remote process instructs the server 206 
that it is relinquishing access to a file. In such a case, the file 
server 206 checks its file table to determine if the relin- 
quishing of the file affects the manner in which other 
processes may access the file. For example, il aJileJs being 
acce ssed by a process h avir ]fl ffiari-vi r rit' , - a '™ t Vi an d a se cond 
■ process havin g read-onl y access T there can J be^nQjopp ortu- 
n istic lock"on the file,. However, if either process relin- 
quishes the file, then the remaining process will be granted 
an opportunistic lock to the file. 

At step 280, the remote process transmits a notice through 
its first socket to the server 206 that it is relinquishing access 
to a file, e.g. closing the file. The server 206 then examines 
the file table 220 to determine whether that process had 
read-only or read-write authorization to the file (step 282). 
If the process had read-only authorization, the server 206 
updates its file table 220 and responds to the relinquishing 
process that it has received notification that the file has been 
relinquished (step 284). In such a case, the file is simply 
flushed from the local cache memory of the client and no 
network transmission of the file is necessary. 

It should be appreciated that the routine does not end at 
this point, but rather, consistent with the system's dynamic 
file allocation, the server 206 determines whether access to 
the file should be modified. Specifically, the server 206 
analyzes the file table 220 for two preliminary inquiries. The 



relinquishing process had read- write access to the file, then 
the server 206 must determine from the file table 220 
whether any other processes presently have access to the fi le 
(step 302 of FIG. 7B). If not, th e file isjpr esently bein g 
maintained in the cache memory ofihe relinquishin g proce ss 
by. wav_pJLa^op portumsIic~ lock , and the server 20fc must 
retrieve any modified portions of that file. A ccordinglY.ih e 
seiyej-2P 6.^ n ds an ?cltnrrw1 ejflgement oTthe relinquishin g 
of the file to the process and receives any modified portion s 
^^~ftt?rthrnuph the first socket of the relir^uishjng 

le file table^ 



20 



proogskial£52flSi- Th e server 206 then upda tes the! 
22013 refle ct that_no processes presently have access 'tq' the 
file (step 306). The file is then storedfaTthe resource 20*8 of 
and the routine is exited. 
If, however, j he file server, at step 302 determines that 
o feerpfeeesseSpTesentlv do have access to the file, then the 
s erver 206 must ascertain from the file table 220 whetj jerany 
such processes have read-write authorization (step 3ffffT"l f 
n ot, then all remaining processes have read-only authoriz a- 
t ion. and each_QLthe^processes may be granted^noppo rtu- — i 
nj &ticiock on the Ji le. Accordin gly, the server 206u^clates its {AjDckd^Sid 
file iable^ZOat step~3l0 and sends a message to the &corid) XTXtwivlcrnr/ffl/ 
hockey of all remaining processes having access to the h ie, . IHIC^rbfl'IILW 

in dicating that the file may no w be transmitted to theirTo cal ] fa) @thQfK 

cache memory_(step 3LZ)./ Irie s erver 20^ then wajts^ for^ ^ 
respective responses from^the first socket Qf_eacn such 
p rocess requesting the fi le to be transmitted to their l ocal 
memory ^pace ( step 31^,'jj pbn receiving these requests, the 
ser ver'fflijSjransmits the file through the first socke t ofe ; 
such process, 
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If the server 206 determines at step 308 that one or more 
processes do in fact have read-write, authorization to th e file, 
t he serve r~2 06 must first update the file table (step 311) th en 
ascertain from the file table 220 whether more than one 
process presently has access to the file ( step 318). If more 
first is whether any other process presently has access to the 35 man OQC omcr process presently has access to the file, then 



file (step 286), and the second is whether any such processes 
have read-write authorization (step 288). If the answer to 
either of these inquires is no, then no modifications to the 
opportunistic access of the file is necessary and the file 
relinquish routine is complete. 

Similarly, if the server 206 determines at step 290 that 
more than one other remote process presently has access to 
the file, and at least one such process has read-write autho- 
rization (step 290), then the file is presently maintained at 



no opportunistic locks are possible, th ejile remains stored at 
tfafi-sfi iy_er 206 , and the routine is exited, it, However, only 
one other process presently has access to the file, even 
though that access is with read-write, authorization^ the 
40 process is granted an opportunistic lock to jhe file which is^ 
t r^psmitted to the cache memory space_of m^proces san the 
manner described at steps 312 and 314 above^__ 



The foregoing description of the preferred embodiments 
of the invention has been presented for purposes of illus- 
the server 206 and no modifications to the opportunistic 45 Nation and description. It is not intended to be exhaustive or 
access is necessary. to limit the invention to the precise form disclosed. Obvious 

If the server determines at step 290 that only one other modifications or variations are possible in light of the above 
process has present access to the file, and such access is teachings. The embodiment discussed was chosen and 
read- write authorization, then the file is also presently stored described to provide the best illustration of the principles of 
at the server 206. However, since the relinquishing process 50 the invention and its practical application to thereby enable 
is relinquishing access to the file, the file having read-write one of ordinary skill in the art to utilize the invention in 
access remains the only process having access to the file. various embodiments and with various modifications as are 
Therefore, the one remaining process is granted an oppor- suited to the particular use contemplated. All such modifi- 
tunistic lock and the file is transmitted to the process to be cations and variations may be within the scope of the 
maintained at its local cache memory space (step 292). To 55 invention as determined by the appended claims when 
effectuate this transfer, the server 206 transmits a message to interpreted in accordance with the breadth to which they are 

the second socket of the remaining process, indicating that fairly, Jegallyrand-equiUbly^nJitled. 

the file is available for an opportunistic lock. The server 206 <r^What is claimed is: 

then waits at step 294 for that process to request the file to 1. A method for managing file access in a computer 
be transmitted. If a timeout occurs at step 296, then the go system having a server process with a file directed for shared 



server 206 assumes that a message packet was lost and will 
retransmit the message (step 298). When the server 206 
receives a request from the remaining process to transmit the 
file, then the server 206 transmits the file to the first socket 
of the remote process (step 300). 

In keeping with the description of the file relinquishing 
routine, if the file server determines at step 282 that the 



usage, a first and a second client processes, a first 
bi-directional communication channel between the first cli- 
ent process and the server, a second bi-directional commu- 
nication channel between the second client process and the 
65 server, and a signaling channel between the server and the 
first and second client processes, the method comprising the 
steps of: 
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transmitting by the first client through the first commu- 
nication channel a request to the server for the file; 

transmitting by the server the file to the first client through 
the first communication channel; 

notifying the first client by the server that the first client 
has an opportunistic lock on the file; and 

sending by the server a message to the first client through 
the signaling channel that the client must relinquish the 
opportunistic access to the file. 

2. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 1. 

3. The method of claim 1, further comprising the step of 
determining by the server whether the file is available to the 
client for opportunistic access; and 

wherein the sending by the server step is performed when 
the server determines that opportunistic access is no 
longer available. 

4. The method of claim 3, further comprising the steps of: 
transmitting by the first client through the first commu- 
nication channel a notification request to the server that 
the first client is relinquishing access to the file; 

determining by the server whether the relinquished file is 
available for opportunistic access by the second client; 
and 

notifying the second client by the server through the 
second communication channel that the file is available 
for opportunistic access. 

5. The method of claim 1, wherein the signaling channel 
is bi-directional between the first client and server. 

6. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 5. 

I. The method of claim 1, wherein the first and second 
client processes have independent signaling channels from 
the server. 

8. The method of claim 7, wherein the signaling channels 
between the server and the first and second clients are 
bi-directional. 

9. A method for allocating and managing files in a 
multi-user network environment of the type having at least 
one server with a file directed for shared usage, and a 
plurality of clients interconnected with the server through a 
network link, each client having at least two identifier 
sockets, wherein a first identifier socket is configured for 
bi-directional communication between the client and the 
server and a second identifier socket is configured for 
communications initiated by the server, the method com- 
prising the steps of: 

transmitting by the client through said first identifier 

socket a request to the server for the file; 
transmitting by the server the file to the requesting client 

through the first identifier socket; 
notifying the client by the server whether the client has an 

opportunistic lock on the file or whether the file must be 

maintained at the server; and 
sending by the server a message to the client through the 

second identifier socket that the client must relinquish 

the opportunistic access to the file. 

10. The method of claim 9, wherein the second identifier 
socket is configured for bi-directional communications. 

II. The method of claim 9, wherein the second identifier 
socket is configured for unidirectional communications. 
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12. The method of claim 11 further comprising the steps 
of: 

transmitting by the client through the first identifier socket 
a notification request to the server that the client is 
5 relinquishing access to the file; 

determining by the server whether the relinquished file is 
available for opportunistic access by a second client 
accessing the file; and 
notifying the second client by the server through the 
10 second identifier socket of the second client that the file 
is available for opportunistic access. 

13. The method of claim 11 further comprising the step of 
relinquishing by the client the opportunistic lock on the file 
by transmitting to the server any portions of the file that have 

15 been modified by the client. 

14. The method of claim 11 wherein the step of deter- 
mining whether the file is available to the client for oppor- 
tunistic access includes the step of referencing an opportu- 
nistic file table maintained by the server comprising 
information related to which clients have open access to the 

20 file and whether the file is open for read-only or read-write 
access. 

15. The method of claim 12 wherein the step of deter- 
mining whether the file is available to a second client for 
opportunistic access includes the step of referencing an 

25 opportunistic file table maintained by the server comprising 
information related to which clients have open access to the 
file and whether the file is open for read-only or read-write 
access. 

16. A computer-readable medium having computer- 
30 executable instructions for performing the steps for a 

method for allocating and managing files in a multi-user 
network environment of the type having at least one server 
with a file directed for shared usage, and a plurality of clients 
interconnected with the server through a network link, each 

35 client having at least two identifier sockets, wherein a first 
identifier socket is configured for bi-directional communi- 
cation between the client and the server and a second 
identifier socket is configured for unidirectional communi- 
cations initiated by the server, the method comprising the 

40 steps of: 

transmitting by the client through said first identifier 
socket a request to the server for the file; 

determining by the server whether the file is available to 
the client for opportunistic access; 
45 transmitting by the server the file to the requesting client 
through the first identifier socket; 

notifying the client by the server whether the client has an 
opportunistic lock on the file or whether the file must be 
5Q maintained at the server; and 

sending by the server a message to the client through the 
second identifier socket that the client must relinquish 
the opportunistic access to the file when the server 
determines that opportunistic access is no longer avail - 

55 a b* e - 

17. The computer-readable medium of claim 16, further 
comprising computer-executable instructions for performing 
the steps of: 

transmitting by the client through the first identifier socket 
60 a notification request to the server that the client is 
relinquishing access to the file; 
determining by the server whether the relinquished file is 
available for opportunistic access by a second client 
accessing the file; and 
65 notifying the second client by the server through the 
second identifier socket of the second client that the file 
is available for opportunistic access. 
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18. The computer-readable medium of claim 16, further 
comprising computer-executable instructions for performing 
the steps of relinquishing by the client the opportunistic lock 
on the file by transmitting to the server any portions of the 
file that have been modified by the client. 

19. The computer-readable medium of claim 16, wherein 
the step of determining whether the file is available to the 
client for opportunistic access includes the step of referenc- 
ing an opportunistic file table maintained by the server 
comprising information related to which clients have open 
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access to the file and whether the file is open for read-only 
or read-write access. 

20. The computer-readable medium of claim 17, wherein 
the step of determining whether the file is available to a 
5 second client for opportunistic access includes the step of 
referencing an opportunistic file table maintained by the 
server comprising information related to which clients have 
open access to the file and whether the file is open for 
read-only or read-write access. 

10 

* * * * * 



04/17/2002, EAST Version: 1.03.0002 



UNITED STATES PATENT AND TRADEMARK OFFICE 
CERTIFICATE OF CORRECTION 



PATENT NO. ; 5,978,802 

DATED November 2, 1 999 

INVENTOR(S) : Hans Hurvig 

It is certified that error appears in the above-identified patent and that said Letters Patent 
is hereby corrected as shown below: 

ON THE TITLE PAGE: 

In Abstract, line 10: "unidirectional" should read -uni -directional- 



Signed and Sealed this 
Twenty-fifth Day of July, 2000 



Attest: 




Q. TODD DICKINSON 



Attesting Officer 



Director of Patents and Trademarks 



04/17/2002, EAST Version: 1.03.0002 



DOCUMENT- IDENTIFIER: US 5978802 A 

TITLE: System and method for providing opportunistic file access in a 

network 

environment 

KWIC 

DEPR: 

The second socket 216, called the message socket, is generally used by 
the 

server to notify the client if it has a message (for example, from 
another 

client on the network) for the client. If the client desires the 
contents of 

the message, the client makes such a request to the server via the main 
socket 

214. As described in more detail below, this second socket 216 has 
been 

adapted for use by the server 206 in connection with the present 
invention to 

submit requests to the client 202, namely to release its opportunistic 
lock on 

files that are maintained in the client cache memory 210. 
DEPR: 

If the file server 206 at step 254 determines that the remote process 
requests 

read-write authorization for the file, then it checks its file table 
220 to see 

if any other process presently has read-write access to the file (step 
270) . 

If not, then the file is being maintained in the local memories of the 
other 

remote processes by way of an opportunistic lock. Accordingly, the 
server 206 

transmits a message to the second socket of each of these processes, 
requesting 

each process to relinquish opportunistic access and control of the 
requested 

file (step 272) . The server 206 then waits for each process so 
requested to 

transmit an acknowledgement through its first socket that it has 
relinquished 

opportunistic access and control of the file (step 274) . It should be 
appreciated, that since these processes have read-only authorization to 
the 

file, that the file may simply be flushed from their cache memories, 
and does 

not need to be transmitted over the network link. If all such 
requested 

processes have not responded to the server 2 06 within a pre-determined 
period 

of time (e.g. 50 milliseconds) , the server 206 will timeout and assume 
that a 



